1. The Field of the Invention
The present invention generally relates to policies defined in a distributed system such as a web service environment. More specifically, the present invention provides a mechanism for normalizing policy expressions into concise policy alternatives for compatibility and compliance purposes.
2. Background and Related Art
Computer systems and related technology affect many aspects of society. Indeed, the computer systems' ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, database management, etc.) that prior to the advent of computer systems were performed manually. More recently, computer systems have been coupled to one another to form computer networks over which the computer systems can communicate electronically to share data. Web services have been a driving force in advancing such communications between systems and are turning the way we build and use software inside-out.
Web services let applications share data, and—more powerfully—invoke capabilities from other applications without regard to how those applications were built, what operating system or platform they run on, and what devices are used to access them. Web Services are invoked over networks, including the Internet, by means of industry-standard protocols including SOAP (Simple Open Access Protocol), XML (eXtensible Markup Language), UDDI (Universal Description Discovery Integration), WSDL (Web Service Description Language), etc. Although web services remain independent of each other, they can loosely link themselves into a collaborating group that performs a particular task.
Often, electronic communication in a web services environment includes a client computer system (hereafter referred to as a “client” and/or “requestor”) requesting access to a network service (e.g., web services) at a server computer system (hereinafter referred to as a “service” and/or “provider”). Accordingly, the client sends a request to the service for particular access to its system resources, wherein if the client is authorized and validated the service responds with a response message providing the desired information. Of course, this request/response type communication (and other message exchange patterns) is governed by various requirements and capabilities defined typically by the service provider in what is termed web service policies or policy documents.
Web service policies define a framework and a model for expression of various requirements and capabilities as policies. Policy expressions allow for both simple and declarative assertions as well as more sophisticated conditional assertions. Further, some assertions specify traditional requirements and capabilities that will ultimately manifest on the wire (e.g., authentications scheme, transport protocol selection). Other assertions specify requirements and capabilities that have no wire manifestation yet are critical to proper service selection and usage (e.g., privacy policy, Quality of Service (QoS) characteristics, etc.). In any event, web service policies provide a single policy grammar to allow both kinds of assertions to be reasoned about in a consistent manner. Typical, web service policies define: (a) an XML data structure called policy expression which contains domain-specific web service policy information; and (b) a core set of grammar elements to indicate how the contained policy assertions apply. The policy document can be applied to any service or client to configure a web service communication for appropriate security, transports, reliability, transactions, etc.
The assertions within a policy expression may be constrained by a number of various logical operators. These operators may combine a group of assertions through such logical expressions as ExactlyOne, OneOrMore, All, or other similar semantics. In addition, the logical operators may be embedded or appear as attributes within the assertion itself. For example, the operators may define such things as whether or not the assertion is Required, Optional, Observed, and other similar constraints. In fact, these logical operators can be arranged in any number of ways to combine and constrain the assertions within a policy expression as per the desires of the service provider or developer. Although web service policies allow a developer a flexible and extensible model for expressing their requirements, capabilities, and general characteristics, there are still several shortcomings and downfalls to such an expansive model.
For example, distributing endpoints often support more than one mechanism of formatting, communicating, and securing messages. To allow two endpoints to determine if they share any of these mechanisms, they need a common way to express acceptable alternatives and to determine if they have any compatible alternatives. Because of the expansive and varied use of the operators for expressing one's policy, however, it is often times difficult to determine such compatibility. For example, consider the hypothetical policy expressions shown in FIG. 1. Policy expression A 105 uses two ExactlyOne operators to express the equivalent of the All operator in policy expression B 110.
Although this simple example of two seemingly different policy expression can be easily identified by a human as equivalent, more complex policy expression are not so easily recognizable. In addition, it is obviously desirable to have the recognition of an endpoint's capabilities, requirements, and general characteristics automated. Note, however, that a string-to-string comparison of the two seemingly different policy expressions in FIG. 1 would yield an indication that the two policy expressions 105, 110 were different.
Moreover, web service policies and other works do not define a mechanism to represent consistent alternatives across one's requirements. For instance, an endpoint might support text encoding where the connection channel is shared for multiple messages and where messages are secured using transport-layer security. Alternatively, an endpoint might support binary encoded messages that are streamed one per connection where the messages are secured using message-level security. Currently, however, there is no mechanism for expressing such capabilities as alternatives. As a further consequence of not providing a mechanism for expressing policy alternatives, current policy models do not provide a way to support versioning of different applications. Additionally, current systems do not define a way to determine compatibility between alternatives supported by different endpoints. Instead, web services and other systems simply assume that policies are expressed from the point of view of one endpoint (typically the service provider) and imposed on the other (the client).
Accordingly, there exists a need for a policy framework that provides an extensible model for: (1) expressing individual capabilities and requirements as consistent alternatives; and (2) determining compatibility between two such policy alternatives.